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(57) Abstract: The invention is a method for a multiple smart card simulator. 
The invention allows cards with different characteristics such as memory, com- 
mand sequence, error handling, and data flow to be simultaneously simulated. It 
also permits simultaneous simulation of different smart card user applications. 
The method involves determining the characteristics of smart cards, and then 
modifying input and output to or from these cards based on the smart card char- 
acteristics. In this way, an end-to-end simulation environment is provided. 
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Title: METHOD FOR A MULTIPLE SMART CARD SIMULATOR 

This application claims priority from U.S. provisional application 60/138,679 filed June 14, 1999. 

Field of Invention 

The present application relates to a method for a multiple smart card simulator, and in particular, an 
application employing multiple simulated smart-cards where the applications running on, or enabled 
on, some of the smart cards differ fix)m those applications running on, or enabled on, other of the 
simulated smart cards, and where the smart cards may have different characteristics. 

Backpround to Invention 

Smart cards are hardware devices that typically have the shape and size of a credit card. Often they 
have an embedded computer processor, memory and an operating system. Often smart cards have 
stored in their memory information related to the user of the smart card. Such information can 
include: 

(i) personal information, such as name, address, other contact information, date of birth, 
etc.; 
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(ii) financial information, such as bank account niunbers and type of account, account 
balances and transaction histories, retirement savings plan information, investment 
information and investment portfolio and account information; 

(iii) medical information, such as medical history and known allergies and prescription 
history; 

(iv) information related to retail shopping, such as clothing sizes, shopping histories and 
product, preferences; and 

(v) other information relating to taste, style and economic, social or cultural activity. 

4 * 

Smart cards are inserted into card terminals which may include automated teller machines, internet 
kiosks, pay telephones, point of sale terminals, cellular phones, or any device containing a card 
reader. 

Using the information stored on the smart card, the card terminals provide a variety of services and 

* 

computer-based applications to the user of the smart card. These services can include: 

(i) paying bills, transferring money between accounts, making investments, analyzing 
a portfolio; 
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(ii) ordering prescription drugs, providing infonnation to health care professionals or 
receiving infonnation from them; 

(iii) buying or selling consumer goods, receiving product information, participating in 
consumer surveys, receiving promotional offers, customizing products; and 

(iv) playing games or receiving other content such as music, video, text or images. 

Different users of smart cards may want to use different applications for a variety of reasons: smart 
cards may have different capabilities, users may have different needs and preferences, users may be 
authorized to use different applications. 

Developers of smart card applications often prefer to develop these applications in a simulated 
environment. In the simulated environment, many hardware elements of the system such as the 
smart card, cardreader and card terminal are simulated. This allows the developer to test and 
develop function, eliminate error, and improve performance of the system without the cumbersome 
and costly need to implement all of the hardware elements. 

Current simulation environments, such as the Java Card^ simulation environment suffer the 
drawback that they are unable to simulate an application that deals with multiple smart cards where 
those smart cards have different applications or where the smart cards have different characteristics. 
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Sumfnary of Invention 

The purpose of the present invention is to provide a method and apparatus for simulating a smart- 
card-based computer appUcation. 

An advantage of the invention is that it supports multi-application card environments. Another 
advantage of the present invention is that it allows simultaneous simulation of smart cards with 
different characteristics. A further advantage is that it allows simulation of the smart card, card 
reader, terminal, and user application in a single development workstation. 

In one embodiment of the present invention there is provided a method for a multiple smart card 
simulator. 



Description of Figures 

Figure 1 shows a flow chart describing an embodiment for the present invention; 
Figure 2 shows a flow chart describing an embodiment for the present invention; 



Figure 3 shows a flow chart describing an embodiment for the present invention. 

4 
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Detailed Description 

Smart cards often have different characteristics. These characteristics include available memory, the 
manner in v^ch they handle error conditions, the command sequence to be input or the data 
retumed from a command sequence. Smart cards often also have idiosyncratic qiiirks or bugs. 
These characteristics and quirks must be simulated in order to have an effective simulation. 

The present invention provides a method for providing a multiple smart card simulator. In one 
embodiment, as set out in figure 1, the following steps occur: 

(i) storing a first set of characteristics of a first smart card (step 1 00). These are stored 
in memory in the developer's workstation; 

(ii) creating a first smart card simulator simulating operation of said first smart card (step 
105). The simulator operates by processing data in the same way that a real smart 
card would; 

(iii) storing a second set of characteristics of a second smart card (Step 1 1 0); 
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(iv) simulating operation of said second smart card thereby creating a second smart card 
simulator (step 1 1 5). The simulator operates by processing data in the same way that 
a real smart card would; 

(v) receiving a first input from a first smart card application (step 1 30). As used herein, 
smart card applications refer to user applications running on the developer's work 
station or on a simulated terminal and not to thin or trivial applications running only 
on the smart card; 

(vi) modifying said first input based on said first set of characteristics (step 140); 
(vih) sending a first modified input to said first smart card simulator (step 1 50); 

(viii) modifying said first input based on such second set of characteristics to form a 
second modified input; and sending the second modified input to said second smart 
card simulator (steps 1 55 and 1 60). The second simulator needs a different modified 
input because it has different characteristics; 

(ix) receiving a first output from said first smart card simulator generated in response to 
said first modified input (step 170), The output is generated by the simulator by 
methods known to those skilled in the art; 
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(x) modifying said first ou^ut based on said first set of characteristics to form a first 
modified output (step 1 80); 

(xi) transmitting said first modified output to said smart card application (step 1 90); 

(xii) receiving a second output firom said second smart card simulator generated in 
response to said second modified input (step 200). The output is generated by 
means to those skilled in the art; 

(xiii) modifying said second output based on said second set of characteristics to form a 
second modified output (step 210); 

(xiv) transmitting said second modified output to said smart card application (step 220); 

In another embodiment, a method is provided for simultaneously running different applications on 
different smart cards. This method is shown on Figure 2 and comprises the following steps: 

(i) receiving a second input firom a second smart card application (step 300); 

(ii) modifying said second input based on said first set of characteristics (step 310); 



(iii) sending a third modified input to said first smart card simulator (step 320); 
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(iv) receiving a third output from said first smart card simulator in response to said third 
modified input (step 330); 

(v) modifying first said third output based on said first set of characteristics (step 340); 

(vi) transmitting said third modified ou^ut to said second smart card application (step 
350); 

One important aspect of the invention is the abiUty to simulate card insertion. Depending on the 
characteristics of the inserted card, different applications may be do^vnloaded into the card. This 
method is shown in Figure 3 and comprises the steps: 

(i) generating a simulated smart card insertion (step 400); 

(ii) determining characteristics of the inserted card (step 405); 

(iii) notifying registered listeners (step 410); 

(iv) determining available applications (step 420); 



8 



wo 00/77750 PCT/CAOO/00703 

(v) downloading to a simulated smart card and to a simulated terminal at least one smart 
card application (step 430) and 

(vi) repeating (steps 400 - 430) 

In the above methods it may be advantageous to simulate Java Cards, for which many development 
tools currently exist and for which the same program code can run in the actual smart card and in the 
simulator, namely the Java programming language. 

Further details are set out in appendix A "Alchemy: Science and Magic for Intelligent Devices" 
especially sections S and 5.1 and in co-pending U.S. applications 09/332,069 titled "Method and 
Apparatus for Incremental Download from Server to Client" , 09/3 32, 191 titled "Method and System 
of Deploying an Application between Computers", 09/332,192 titled "Method and System for 
Remotely Observing and Controlling Objects and 09/332,193 titled "Method and System for 
Managing and Using Persistent Storage all of which are incorx)orated by reference. 
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We claim: 



1 . A method of providing a multiple smart card simulator comprising: 



(i) storing a first set of characteristics of a first smart card; 



(ii) creating a first smart card sunulator simulating operation of said first smart card; 



(iii) storing a second set of characteristics of a second smart card; 



(iv) simulating operation of said second smart card thereby creating a second smart card 
simulator; 



(v) receiving a first input from a first smart card application; 



(vi) modifying said first input based on said first set of characteristics; 



(vii) sending a first modified input to said first smart card simulator; 
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(viii) modifying said first input based on such second set of characteristics to form a 
second modified input; and sending the second modified input to said second smart 
card simulator; 

(ix) receiving a first output Grom said first smart card simulator generated in response to 
said first modified input; 

(x) modifying said first output based on said first set of characteristics to form a first 
modified output; 

Ou) transmitting said first modified output to said smart card application; 

(xii) receiving a second output from said second smart card simulator in response to said 
second modified input; 

(xiii) modifying said second output based on said second set of characteristics to form a 
second modified output; and 

(xiv) transmitting said second modified output to said smart card application. 



2. 



The method of claim 1 where said characteristics include one of the smart caids memory 
size, command sequence, error handling routine or quirks. 
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The method of claim 1 further comprising the steps: 



(i) receiving a second input firom a second smart card application; 



(ii) modifying said second input based on said first set of characteristics; 



(iii) sending a third modified input to said first smart card simulator; 



(iv) receiving a third output firom said first smart card simulator in response to said third 
modified input; 



(v) modifying first said third output based on said first set of characteristics; 



(vi) transmitting said third modified output to said second smart card application. 



A method of simulating a multiple smart card enviroimient comprising: 



(i) detecting a simulated smart card insertion (step 400); 



(ii) determining characteristics of the inserted card (step 405); 
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(iii) notifying registered listeners (step 4 1 0); 

(iv) determining available applications (step 420); 

(v) downloading to a simulated card and to a simulated terminal at least one smart card 
application (step 430) and 

(vi) repeating (steps 400 - 430). 
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Figure 1 



Step 100 



Storing first set of characteristics of first 
smart card. 




1 

▼ 


Step 105 


Simulating operation of first smart card - 

creatina a first smart card simulator 






Step 110 


Storing second set of characteristics of 
second smart card. 






Step 115 


Simulating operation of second smart card 
- creatinq a second smart card simulator. 






Step 130 


Receiving input from a smart card 
aDolication. 




▼ 


Step 140 


Modifying Input from step 130 based on 
characteristics of first smart card. 






Step 150 


Sending modified input to first smart card 
simulator 






Step 155 



Modifying input from step 130 based on 
characteristics of second smart card. 



Step 160 



Sending modified input to second smart 
card simulator. 






Step 170 


Receiving output from first smart card 
simulator. 







Modifying output from first smart card 
simulator with first set of characteristics of 
first smart card. 






Step 190 


Transmitting first modified output to smart 
card aoolication. 






Step 200 


Receiving output from second smart card 

simulator. 




1 

T 


Step 210 


Modifying output from second smart card 
simulator with second set of 
characteristics of second smart card. 




1 

T 




Step 220 



Transmitting second modified output to 
smart card application. 



wo 00/77750 



2/3 



PCT/CAOO/00703 



Figure 2 
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METHOD FOR A MULTIPLE SMART CARD SIMULATOR 

This application claims priority from U.S. provisional application 60/138,679 
5 filed June 14, 1999, 

Field of Invention 

The present application relates to a method for a mxiltiple smart card simulator, 
and in particular, an ^plication employing multiple simulated smart-cards where 
10 the applications running on, or enabled on, some of the smart cards differ from 
those applications running on, or enabled on, other of the simulated smart cards, 
and where the smart cards may have different characteristics. 

Background to Invention 
IS Smart cards are hardware devices that typically have the shape and size of a credit 
card. Often they have an embedded compute processor, memory and an 
operatiag system. Often smart cards have stored in their memory information 
related to the user of the smart card Such information can include: 

20 (i) personal information, such as name, address, other contact 

information, date of birth, etc.; 

(ii) financial information, such as bank account numbers and type of 
account, account balances and transaction histories, retirement 
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savings plan infonnati oii, investment infoimation and investment 
portfolio and account information; 



(iii) medical information, such as medical history and known allergies 
and prescription history; 



(iv) information related to retail shopping, such as clothing sizes, 
shopping histories and product, preferences; and 



10 (v) other information relating to taste, style and economic, social or 

cultural activity. 



Smart cards are inserted into card terminals which may include automated teller 
machines, internet kiosks, pay telephones, point of sale terminals, cellular phones, 
IS or any device containing a card reader. 



Using the information stored on ttie smart card, the card terminals proAdde a 
variety of services and computer-based applications to the user of the smart card. 
These services can include: 

20 

(i) paying bills, transferring money between accounts, making 
investments, analyzing a portfolio; 
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(ii) ordering prescription drugs, providing information to health care 
professionals or receiving information from them; 



10 



(iii) buying or selling consumer goods, receiving product information, 
participating in consume surveys, receiving promotional offers, 
customizuig products; and 



(iv) playing games or receiving other content such as music, video, 
text or images. 



Different users of smart cards may want to use different applications for a variety 
of reasons; smart cards may have different capabihties, users may have different 
needs and preferences, users may be authorized to use different ^phcations. 



IS Developers of smart card applications often prefer to develop these applications 
in a simulated environment. Li the simulated environment, many hardware 
elements of the system such as the smart card, cardreader and card tenninal are 
simulated. This allows the developer to test and develop function, eliminate 
eiror, and improve performance of the system without the cumbersome and costly 

20 need to implement all of the hardware elements. 

Current simulation environments, such as the Java Card^ simulation 
environment suffer the drawback that they are unable to simulate an application 
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that deals with multiple smart cards where those smart cards have different 
applications or where the smart cards have different characteristics. 

Summar y nf Invention 

5 The purpose of the present invention is to provide a method and apparatus for 
simiilating a smart-card-based computer appUcation. 

An advantage of the invention is that it supports multi-appUcation card 
enviroimients. Another advantage of the present mvention is that it allows 
10 simultaneous simulation of smart cards with different characteristics. A further 
advantage is that it allows simulation of the smart card, card reader, terminal, and 
user appUcation in a single development workstation. 

In one embodiment of the present invention there is provided a method for a 
15 multiple smart card simulator. 

Description of Fi^es 

Figure 1 shows a flow chart describing an embodiment for the present invention; 
20 Figure 2 shows a flow chart describing an embodiment for the present invention; 
Figure 3 shows a flow chart describing an embodiment for the present invention. 
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Detailed Description 

Smart cards often have different characteristics. These characteristics include 
5 available memory, the manner in which they handle error conditions, the 
commaad sequence to be laput or the data returned firom a command sequence. 
Smart cards oft^ also have idiosyncratic quirks or bugs. These characteristics 
and quirks must be simulated in order to have an effective simulation. 

10 The present invention provides a method for providing a multiple smart card 
simulator. In one embodiment, as set out in figure 1, the following steps occur: 



(i) 



storing a first set of characteristics of a first smart card (step 1 00). 



These are stored in memory in the developer's workstation; 



15 



(ii) creating a first smart card simulator simulating operation of said 



first smart card (step 105). The simulator operates by processing 



data in the same way that a real smart card would; 



20 



(iii) storing a second set of characteristics of a second smart card (Step 



110); 
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(iv) simulating operation of said second smart card fhoreby creating a 
second smart card simulator (step 1 IS). The simulator operates 
by processing data in the same way that a real smart card would; 



10 



(v) receiving a first input from a first smart card application (step 
130). As used herein, smart card applications refer to user 
applications running on the developer's work station or on a 
simulated terminal and not to thin or trivial applications running 
only on the smart card; 



(vi) modifying said first input based on said first set of characteristics 
(step 140); 



(vii) sending a first modified input to said first smart card simulator 
15 (step 150); 



(viii) modifying said first input based on such second set of 
characteristics to form a second modified input; and sending the 
second modified input to said second smart card simulator (steps 
20 155 and 160). The second simulator needs a difiTerent modified 

input because it has different characteristics; 



(ix) receivmg a first output firom said first smart card simulator 
generated in response to said first modified input (step 170). The 
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output is generated by the simulator by methods known to those 
skilled in the art; 



(x) modifying said first output based on said first set of characteristics 
to form a first modified output (step 180); 



(xi) transmittiag said first modified output to said smart card 
application (step 190); 



10 (xii) receiving a second output from said second smart card simulator 

generated in response to said second modified input (step 200). 
The output is generated by means to those skilled in the art; 



(xiii) modifying said second output based on said second set of 
15 characteristics to form a second modified output (step 210); 



(xiv) transmitting said second modified output to said smart card 
appUcation (step 220); 



20 In another embodiment, a method is provided for simultaneously rutming 
different apphcations on different smart cards. This method is shown on Figure 
2 and coniprises the following steps: 
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(i) receiving a second input fiom a second smart card application 
(step 300); 



modifying said second 
characteristics (step 310); 



(iii) sending a third modified input to said first smart card simulator 
(step 320); 



10 (iv) receiving a third output from said first smart card simiilator in 

response to said third modified input (step 330); 



(v) modifying first said third output based on said first set of 
characteristics (step 340); 

(vi) transmitting said third modified output to said second smart card 
apphcation (step 350); 



One important aspect of the invention is the abiUty to simulate card insertion. 
20 Depending on the characteristics of the inserted card, different applications may 
be downloaded into the card. This method is shown in Figure 3 and comprises 
the steps: 

(i) generating a simulated smart card insertion (step 400); 
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(ii) 



detennming characteristics of the inserted card (step 405); 



(iii) 



notifying registered listeners (step 410); 



(iv) 



detennining available applicatioxis (step 420); 



(V) 



downloading to a simulated smart card and to a simulated 



terminal at least one smart card plication (step 430) and 



10 



(vi) repeating (steps 400 - 430) 

In the above methods it may be advantageous to simulate Java Cards, for which 
many development tools currently exist and for which the sameprogramcode can 
IS run in the actual smart card and in the simulator, namely the Java programming 
language. 

Further details are set out in sqppendix A "Alchemy: Science and Magic for 
InteUigent Devices" especially sections 5 and 5.1 and in co-pending U.S. 
20 applications 09/332,069 titled "Method and Apparatus for Incremental Download 
from Server to Client", 09/332,191 titled "Method and System of Deploying an 
AppUcation between Computers", 09/332,192 titled "Method and System for 
Remotely Observing and Controlling Objects and 09/332,193 titled "Method and 
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System for Managing and Using Persistent Storage all of which are incorporated 
by reference. 
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APPENDIX A 




Alchemy™: 
Science and Magic 
For Intelligent Devices 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 



PCT/CAOO/00703 



-12- 



Table of Contents 



1 Introduction - 

2 Architectural Overview 

3 Alchemy™ Core Framework v 

: 3.1 System Configuration ; 

. 1.2 Persistent Storage : 

1.3 JAR Repository 

1 .4 Managed Bean Repository « 

1 .5 Communications Adapters 

1 .6 System Initialization 

1.7 Idle Detection : 

4 Application Services .'.„.. 

4.1 MuM- Application Architecture 

4.2 Options Management ^ 

• 4.3 Language Management 

4,4 AWT Services....; « 1< 

5 Smart Card Services - L 

5.1 Java Card I 

6 Telephony Services 1- 

6.1 Modem Services 1- 

1 2 Basic Telephony Services I 

1 .3 Advanced Telephony Services 1 

7 Internet Services 1 

7.1 PPP and Auto Dial 1 

7.2 Internet Applications 1 

7.3 Custom XJRL Handling 1 

8 Observation and Control Services 1 

8.1 Ohservation and Control Architecture ;. 1 

8.2 Alchemy™ Observer/Controllers 1 

8.3 Al<*emy Probe I 

8.4 Device Management Gateway - 1 

9 Development Bnvlronment 2 

10 Appendix A - Touchstone*^*^ 2 



Table of Figures 

Figure I - Alchemy^ Architecture 

Figure 2 - Idle Management Architecture 

Figure 3 - Multi-Application Architecture 

Figure 4 - Options Management Object Relationship 

Figure 5 - Class Structure Language Management 

Figure 6 - Application Selection 

Figure 7 - Sidebar Application Selector .-. k... 

Figure 8 - Comer Application Selector 

Figure 9 - Java Card Environment 

Figure 1 0 - Custom URL Dispatching 

Figure 1 1 - Observation and Control Architecture 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 PCT/CAOO/00703 

Twchstom^cofd Alchemy^ are re^^tered trademarks ofAudeSi Technologies Inc. 

Windows, Windows NT, and Windows 95 are registered trademarks of Microsoft Corporation in the 
•United States and/or other countries. 

PowerPC is a registered trademark of International Business Machines Corporation. . 
OCR 410 is a registered trademark ofGemplus. 

Ja^a^ and ali Java^based trademarks and logos are trademarks or registered trademarks of Sun 
Microsystems, Inc, in the United States and/or other countries. 

JWorks'^ is a registered trademark of WindRbfer Systems. 

All other trademarks used in this document are the property of their respective owners. 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 



PCT/CAOO/00703 



-14- 



Acronyms 




Applicatioii Programming Interface 



Ascn 



American Standard Code for Information Interchange 



ATA 



Advanced Technology Attachment 



AWT 



Abstract Windowing Toolkit 




CPU 



Commmiication Processor Module 



! <h ■ r 



cso 



Chip Select O 




DSP 






Digital Signal Processing 



DRAM 



Dynamic Random Access Memory 



DSYD 



Digital Simultaneous Voice Data 



DTAD 



Digital Telephone Answering Device 



DTMF 



Dual Tone Multi Frequency 





GUI 



HTTP 




Graphical User Interfece 



Hyper Text Transmission Protocol 



Input/Output 



ISDN 



Integrated Services Digital Network 



ISO 



Intemadonal Organization for Standardization 



ISP 



Internet Service Provider 




JNT 



Java Native Interface 



JVM 



Java Virtual Machine 







LED 



Light Emitting Diode 



LBFO 



Last In, First Out 




' NOR Flash 



Negatiye OR Flash 
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O&C 



Observatioaand Control 





PIM 



Peisonal Informatioii Manager 



POTS 



Plain Old Telephone Service 



PPP 



PoinMo-Point Protocol 



PSTN 



Public Svyitched Telephone Network 




ROM 



Read Only Memory 



RTOS 



Real Time Operating System 




User Interface 



URL 



Uniform Resource Locator 



USB 



Universal Serial Bus 
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1 Introduction 

Advances in Ihtemet; telephooy> and oth^ communications technologies have spurred demand for a wide range 
of new, intelligent devices. Armed wi& these devices, service providers will soon offer a host of new Intmet 
services to a new class of users. Easy access to services wi}l fuel the continuing explosion of the Intmet, 
ultimately creating greater demand for intelligent access devices. As a device manufacturer, ^s is ihp kind of 
chain reaction you want to be right in the middle of. . . but how do you get in the game? Many devices will be 
deployed including screen phones, counter*top tablets, set top boxes, mobile phones, public kiosks, Personal 
Digital Assistants (PDA), etc. Regardless of the device, there are a couple of things to keep in mind, if you are 
going to be successful. 

1 . Your device is gomg to have to be "slick'- so you can diflferentiate yourself from the competition. 

2. The time to market is critical so you wiU want to compress your development time. 

3. Development dollars are scarce so use th^ where they count &e most, on the value add content 

4. People diat know how to put Java™ into embedded appliances are very scarce. Work on getting them now. 

5. The Internet is bigger than you are, so you need a way to integrate the rapidly merging technologies 
wi&out getting buried. * 

What win it take to get this device developed? 

First, you need a hardware solution. You can probably find a reference design as a starting point, but you're 
going to need to build a development board with the proper features for your device. You need to get started 
right away because it wiU take 4 to 6 months. Beyond that timeframe, you will also have to spin a form factor 
board, which will take another 4 to 6 months. 

Next, you need a proper environment and strategy for software development. You need to develop the sofrware 
parallel'to the hardware because you won't see the hardware for several months. Java"*^ is a good choice for 
achieving platform independence and it has "netwoik awareness*' within it Good news comes from your Real 
Tone Operating System (RTOS) .vendor because he has an embeddable Java solution you can deploy on your 
hardware when it's ready. 

It's not a bed of roses yet... you have a full suite of device drivers to write before integrating your software and 
hardware. Better get your RTOS engineers working right away as driver development mi^t end up on the 
critica] path. 

Now, let's move to the application suite. The initial set of applications to be deployed is well defined but the 
dynamic nature of the service environment will inevitably give rise to new requirements. You need a solid multi- 
application infrastructure that allows you to react to changmg requirements... but diere isn't time to do it 
properly for this device. 

So, you take shortcuts and begin to cobble together your application suite. Debugging proves to be more 
complicated than expected because the software is multi-threaded. It would be nice to have debugging tools 
tailored to your architecture, but you don't have time or resources to develop tools. You struggle with traditional 
tools and some rudimentary tracing facilities. 

Eventually, you have a ''mostly working" application suite and hardware platform. You are ready to begin 
. integration but progress is slow. It proves to be non-trivial to configure a target device proper^ and get a Java™ 
software load onto it It would be nice to have a seamless environment covering the entire spectrum from die 
Java™ application suite to RTOS and drivers... but you don't Debugging on the target is evta more challenging 
than on die workstation. You probably should have developed diose test tools but it's too late now. 

Finally, your applications are niiming on the target and are close to achieving the fimctional requirements for the 
device. . . but you aren't out of the woods yet Your boot time is too slow and your memory requirements are too 
large. You need to re-architect your application suite to improve the initialization sequence. Meanwhile, you find 
tools that can help trim down your Java™ load, but they are not well integrated and prove to be cumbersome. 
You make the tools work for you, but you really need to address these environmental issues before your next 
device. 
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You are ready for field trials, but you had to pull all your diagnostic capabilities to achieve a rq)resentalive ' 
software load. You are now flying blind when it comes to debugging anomalies in the field. It would be great to 
have support for remote management and monitoring of the device. You would double benefit from this when it 
comes time to performing automatic regression testing. Put it on the wish list for next time... this device is done! 

It took 18 months to deliver, and cost you over 96-man-months of software effort and 45 man-months of 
hardware resources. You hope you haven't missed your window of opportunity. The next device will go a lot 
smoother now that you've been through it once. At least you hope sol Don't let this description become a brief 
history of your development effort There is a better way. 



Alchemy™ 

Derived fix>m real world experience gained in developing two generations of Java-based intelligent devices, 
AudeSi Technologies Inc. delivers Alchemy™, a unique software and hardware solution targeted at rapid 
development, of intelligent devices requiring Internet, telephony, and/or smart card capabilities. 

Alchemy^ mcludes a Java-based multi-application software firework, a variety of plug-in software services, 
woiidhg example applications, and a comprehensive development and test environment that addresses the full 
spectrum of device-level software development issues. Alchemy™, when integrated witii Touchstone™ and 
associated drivers, provides a superset of hardware cq)abilities required for intelligent devices. This mcludes a 
PowerPC™ based computation engine, multiple memory configurations, an advanced two-line telephony block, 
smart card readers, and a host of I/O capabilities including Ethernet, modem, serial, and universal serial bus 
(USB). Details on Touchstone™ are included m Appendix A. 

The primary goal of Alchemy™ is to reduce the barriers to entry for prospective manu&cturers and developers 
of intelligent devices. Alchemy™ achieves these goals by providing the following. 

1. A Java Native Interface (JNI) provides access to Touchstone'™ hardware platform capabilities fi-om the 
Java™ layer, thus elimmating the need for developers to work with low-level device drivers and RTOS 
issues. 

2. The Alchemy™ Core Framework provides a comprehensive environment for the deployment of an 
extensible multi-application software suite. The framework handles a varied of low-level issues including 
device configuration, initialization sequ^ce, and memory/file-system management, thus allowing the 
developer to concentrate on application level development 

3 . The framework is "Internet Aware" and supports seamless hitegration with network-based server 
envffonments. Two primary capabilities delivered through network awareness are as follows: 

• Remote device management where a server-based application can manage a device for the purpose of 
device configuration, software upgrade, or in-field diagnostics. 

• Distributed framework services where applications can be seamlessly partitioned across the 
device/server environment, ultimately reducing device resource requirements by offloading portions of 
the application onto server resources. 

4. Alc^wny™ is based on the JavaBeans™ programming model, and as such, facilitates development of 
portable and reusable software components, and mtegration with conmieiviaily available Java^'" software 
development tools and environments. 

5. Alchemy™ delivers comprehensive services in support of apphcation development including the following: 

• Application services mchiding application registration, application selection, language management, 
and user preference management 

• Internet services including point-to-point protocol (^PP) and integration of 3"* party browsers and 
email clients.- 

• Smart card services mcludmg Open Card Framework™ (OCF) and Java Card"* support 
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• Telephony services including voice call control state machine, dual tone multi frequency (DTMF) tone 
generation, frequency shift keying (FSK) data reception. Calling Line ID/Spontaneous Caller Waiting 
ID (CLID/SCWID), contact database, and modem control. 

• Observation and control services that fecilitate remote testing of devices. 

• Device Management Gateway services for secured management of device configuration and 
application download. 

Beyond this initial set of services, Alchemy^ will be continually enhanced witii new service offermgs in a 
variety of areas including security and cryptographic support, E-Conunerce protocols, personal information 
manager (PIM) services, and advanced Internet and telephony services. 

6. Alchemy^ includes Rapid Application Development (RAD) objects that leverage available Alchemy™ 
services into functionally complete application implementations. RAD objects can be customized to rapidly 
deliver applications with a device-specific look and feel. 

7. Alchemy*^ inchides a comprehensive set of development tools (e.g., installation tools, system configuration 
tools, debugging and testing tools) that smooth the development process. 

■ * 

Hie remaining sections of this paper describe the ardiitecture and capabilities that Alcheihy™ delivers. 

2 Architectural Overview 

The basic architecture of Alchemy^, as deployed on Toudistone'^, is shown in Figure 1 . . 



DEVICE SERVER 




Figure 1 — Alchemy™ Architecture 
The major components in the device architecture are described below. 
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1 . Touchstone'^ consists of the reference hardware, the KTOS, device driver suite, the PJava 
environment and tfie device driver JNL Touchstone™ currently supports two conunercial RTOS/Java 
environments, namely Sun*s JavaOS4C™, and WindRiver Syst«ns' JWorics™. 

2. Alchsiny ^Core Framework Hie frameworic is the backbone of the software architecture, providing a 
dynamically configurable multi-application firamework and managed bean repository. Managed beans 
represent the active components in the system, and are directly accessible through tiie framework. The 
framework is also responsible for low-level device infrastructure including system configuration, 
device initialization, communications adapters, memory management, file system, persistent storage, 
and JAR management 

3. Alchemy ^System Beans: A variety of system beans are provided with Alchemy. These beans give 
other application beans access to system services such as hardware devices, persistent storage, system 

. properties and application support facilities. 

4. Service Beans: General purpose and application-specific capabilities are provided to the system 

• through service beans. They are device-independent and reusable in natare. Application beans make 
use of service beans to deliver device-specific application capabilities. While Alchemy^ supplies a 
number of service beans, they are most often associated with specific application functionality (e.g., 
the protocol component of an application). 

. 5. Application Beans: The look and feel of a specific application on a specific device is implemented in 
an application bean. An application bean implements the user interface and interacts witii system and 
service beans to achieve the application's intended functionality. Alchemy^ provides a number of 
RAD objects that are designed to deliver fimctional ^plications quickly. RAD objects can be extended 
or modified to deliver device-specific application features. 

6. Communications Adapter: Ilie communications adapter allows for sever-based communication with 
tiie firamework and all managed beans that are registered with the framework. Adapters provide a 
mechanism whereby managed beans within the framework can be manipulated remotely througb a stub 
or client bean. Alchemy™ currently supports HTTP and HTTPS conununications adq}ters. 

The Alcheiny'™ architecture provides direct seamless integration with server applications through the 
firework and communications adapters. While the device/server architecture is general-pujpose in nature, it is 
currently used within the Alchemy™ environment to deliver three key capabilities. 

1 . Device Management Gateway: The gateway is part of the Alchemy^ architecture that supports remote 
management of devices. Througjh a communications adapter, the gateway can interact with the framework 
to provide a number of capabilities, includh\g discovery services, device configuration, and application 
download. Discovery services are used to determine the existing configuration of a device, including 
available resources, existmg software components, and version numbers. Device configuration services 
allow for remote configuration of the s^ces and cq;>plications on the device. Apptication download 
services allow for upgrades to the device software load, including download of new q)plications to the 
device. The gateway is fiilly extensible and can be easily incorporated into any serv^ environment 

2. Remote Testing: Because Alchemy™ supports remote interaction widi the framework and managed beans 
within the framework, it is well suited to remote device testing Alchemy™ includes a flexible and 
extensible observation and control architecture that allows a server-based test tool to monitor and control 
the behavior of managed beans within die fiamework. The observation and control architecture is well 
suited to development time tesfing, automated regression testmg, and in-field testing. 

3. Extended Framework Alchemy™ dfrectly supports the concept of an extended firamework where a slave 
firamework enviroiunent is created on the server and controlled by the device. Using this mechanism, it is 
possible to partition applications in a manner that places most of the application resources on the server 
with only the shell of the application deployed on the device itself. Interaction between the device-resident 
application shell and the server-resident application services is achieved transparentiy through the 
framewodc and the communications adapter. 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 



PCT/CAOO/00703 



-20- 



3 Alchemy^ Core Framework 

Hie framework is the heart of the Alchemy™ architecture and is responsible for establishing and 
maintaining all basic system services, and orchestrating fte device mitialization sequence. The services 
available in the framework are described in the following subsections. 

3.1 System Configuration 

The framework defmes the system configuration through a set of system properties. Hiese properties define 
precisely the underlying capabilities of the device and include information regarding available memory, 
display capabilities, and the existence of I/O devices such as Ethernet, USB, modem, smart card reader, etc» 
In essence, the system properties define a subset of Touchstone™ capabilities that are available to a device- 
specific software load. System properties can be defined through a combination of hard-coded, command- 
line, and property-file entries. After initialization, system properties are made generally available through 
the standard Java system properties. 

TTie system properties can be accessed remotely through discoveiy services m the gateway. 

3.2 Persistent Storage 

Alchemy^** relies on &e existence of sonae form of persistent storage. At a minimum, persistent storage is 
required to hold the software toad itself. To take advantage of fte dynamic capabilities of Alchemy, 
writeable persistent storage is required. Beyond storage of the system itself the framework controls all 
other persistent storage and makes it avail^le to managed beans witidn the system. A variety of flavors of 
persistent memory are supported inchiding NAND Flash. NOR Flash, and EEPROM. Touchstone""* 
provides underlying hardware and driver support for all types of persistent memory. 

Through a set of configuration parameters, the developer can defme any number of contiguous blocks of 
persistent storage within the systems available persistent memory. Once defined, diese persistent storage 
blocks are available for allocation to managed beans through the framework. Hie framework is responsible 
for maintaming a persistent map of persistent storage, and returning the blocks to their respective owners at 
start-up. The framework is also responsible for de-allocation of persistent storage and defragmentation of 
persistent memory. 

Although Alchemy™ does not rely on the existence of a Flash File System (FFS), it does support one. If a 
device is configured witii a FFS, it will exist in a contiguous block of Flash and be made available through 
fte standard Java file system support Tlie FFS can co-exist with fee block-based persistent storage 
mechanism provided by the fiBmework. 

♦ 

3.3 JAR Repository 

The Java software load for a system is maintained in Java Archive Stor^e (JAR) files in persistent storage. 
The JAR Repository is responsible for managing the JARs and adjusting the JVM CaLASSPATH to include 
all available JARs. JARs are separated into three categories as follows: 

1. Java System: The Java System JARs include all the base Java classes the virtual machine (VM) expects. 

2. Alchemy ^System: The Alchemy™ System JARs contwn the entire core Alchemy™ classes used in the 
system including Alchemy™ utility, system, and service classes. 

3. Application: Application JARs contain the device specific application and service classes for a system. 

The CLASSPATH is dynamically constructed with Java System JARs first, Alchemy™ System JARs next, 
and Application JARs last Withm each subset of the CLASSPATH, JARs are maintained in reverse order 
of their registration (e.g., last registered JAR is first). In this vray new JARs can replace obsolete classes m 
older JARs. The JAR Repository can be managed remotely through the gateway to add and remove JARs 
from the system. The JAR Repository is not dependent on a file system, and all JAR dovmloads are 
"guaranteed". 
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3.4 Managed Bean Repository 

Managed beans represent the active components in the system, and collectively, implem^t the capabilities 
of the device. The framework is responsible for maintaining a persistent repository of managed beans, and 
making those beans generally available in the system. Hie following information is associated with each 
managed bean in ^e system. 

1 . Name: The name used to reference the bean. 

2. IDi-k unique identifi^ for the bean. 

3 . Class: The fully qualified class name for the bean. 

4. Type: The type of bean. 

5. Persistent Storage Block List A list that identifies the persistent storage blocks belonging to the bean. 

When a bean is registered with a repository, it iQUSt have a unique name. In tum, the bean is assigned a 
-perman^t miique identifier. A reference to any bean in the repository can be obtained through the 
framework using either the name or the ID of the bean. 

3.5 Communications Adapters 

Hie firework is responsible for establishing any communications adapters that exist m the system. 
Configuration parameters are used to define which ad^ter is used Alchemy"™ supports HTTP and HTEPS 
adapters. If an adapter is not included in the device configuration, remote services will be unavailable. 

3.6 System Initialization 

Tht firework is responsible for performing system mitializatioiL The primary goal of the initialization 
sequaice is to bring the device to life quickly and then complete system initialization in the background. 
The following phases make up the initiah'zation sequence: 

1. The framework establishes its environment including system properties, framework, persistent storage 
maps, and managed bean repository. 

2. The framework establishes application services througih creation of the applicatron manager. The 
application manager is discussed in section 4.1. 

3. The framework creates and registers all application type managed beans. At registration time, managed 
beans are given the opportunity to perform required internal initialization. While not enforceable, 
applications should avoid extensive mitialization work at registration time. Wherever possible, object 
creation and initialization within an application should be deferred to tiie moment that such objects are 
required. 

4. Once all applications are registered, control is transferred from the framewoik to the application 
selector where tiie de&ult idle application is started. Idle applications are discussed in section 4.1 . 

5. In the background, the framework continues to create and register other managed beans m the system 
until it has exhausted tiie list contained in the managed bean repository. Should a running application 
require access to a bean that has not yet been mitialized, that bean will be created aiid registered at the 
time of the request 

3.7 Idle Detection 

Idleness of a device can be used to trigger a number of activities ranging from activation of a screen saver, 
to performing systems maintenance activities such as defragmentation of persistent storage. Alchemy*^ 
provides an idle management service that controls the idle detection process and dispatches events 
indicating system idleness. Two mechanisms are provided for indicating activity m the system. 

1. Spontaneous: The idle manager provides a direct API used to indicate current activity. Any object in 
the system can indicate cunrent activity by making this call. 
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2. Polling: Objects in the system can act as polled activity sources by registering with the idle manager. 
The manager uses a configurable idle timer to set the polling period. On each timer expiration the 
manager polls each source for activity status. 

On eadi idle timer expiration, the manager decides if the device has be^ idle during that period. If it has, 
the manager generates events to ail idle listeners. Idle events include an idle count indicating the current ' 
number of consecutive idle periods. Listeners can use this count to distinguish between vaiying levels of 
idleness. The idle managanent architecture is illustrated m Figure 2. 




Figure 2 - Idle Management Architecture 



4 Application Services 

One of Alchemy's primary goals is to provide an environment that allows the developer to focus on 
application-level development Towards this goal, Alchemy^ provides an extensible multi-application 
architecture in which applications can co-exist. In addition. Alchemy'™' provides a number of common 
application services and RAD objects that further reduce the development cycle for applications. 

By definition, an application must include some user interface component (a means by which the user 
interacts with the application). Unlike traditional computing environments, it is not a certamty that an 
inteUigent device will inchide a fiiU-featured, pomt-and-clidc windowing environment in which the user 
interface (UI) can be dq)loyed. Alchemy™ provides the necessary mjarastracture to support the following 
display environments. 

1 . Abstract Windowing Toolkit (A W7) Windowing Environment. This is the standard Java GUI 
environment that supports graphics, windows, and a pointing device. Standard AWT-based drawing 
components and event mechanisms are applicable to this environment 

2. Seorof-Dots Graphics Environmeni: This type of display supports rudimentary bit-mapped graphics, 
icons, and text A pointing device is not normally associated with this environmeut Configurable soft 
keys may be associated with Ais environment 

3- Alphanumeric Display Environment. This type of display supports some number of lines and columns 
of alphanumeric style text and fixed-size icons. Configurable soft keys may be associated with this 
environment. 

Alchemy*s application services are organized into display-independent and display-dq)endent cq)abilities. 
Display-independent services include the multi-a|5plication ardutecture, qptions management, and language 
management, which are described in section 4.1 through 4.3. Display-dependents«rvices for the three 
display environments are described after the display-independent services. 
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NOTE: The first release of Alchemy'^ includes only AWT-dependent display services. Sea-of-dots and 
alphahuxneric display services are deferred to a subsequent release of Alchemy. 

4. 1 Multi-Application Architecture 

The muM-appUcation architecture in Alchemy^ is supported through an Application Manager that 
provides three basic services as illustrated in Figure 3 and descdbed below: 

1. Application Registration: Before applications are available for selection ftey must be registered with 
the Application Manager. Tlie registry maintains a reference to each ^plication and can activate and 
deactivate applications on demand. Within the registry, a single application is identified as the idle • 
application, which is activated automatically at start-up, and whenever the device becomes idle. The 
registry also generates events indicating when the set of applications is modified. This event 
mechanism supports dynamically modifyhig the set of available applications. 

2. Application Selection: Applications are given: focus and made active by the user trough an application 
selector. Tlie application selector interacts witii the registry to present the user with a selection of 
available applications and effects the activation of ^plications when tiiey are selected. By definition, 
an application selector includes some UI component and as such must be implemented f esc a specific 
display environment Aldiemy^ provides both display-mdependent services for q^plicadon selectors 
as well as display-specific RAD implementations of application selectors. 

3. Application History: A history is maintained when applications are activated and de-activated. When 
an active application is deactivated, the application history determines which application should be 
activated. Alchemy?* provides the base services for application history, as well as a RADO 
implementation of a configurable, fixed-depth, LIFO history. 




Figure 3 - Multi-Application Architecture 



4.2 Options Management 

Most device envhonments have a requirenient for persistent, user settable options. Tliese options range 
fix>m global options that apply across the entire device (e.g., language preference), to application or smice 
specific options. While the scope of options may vary, user access to options is typically available through 
a conuBon access point In a dynamic application environment it becomes necessary for options 
management to become dynamic as well. Alchemy™ provides an extensible options management service 
that facilitates the organization of options, without imposing a specific implementation of options 
management at the UI level. The options service in Alchemy^ provides a base infrastructure .that inchides 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 



PCT/CAOO/00703 



-24- 



an options menu object capable of supporting a hierarcbically representation of options and submenus of 
options, and an abstract option screen object£*om which an actual options editing implementation can be 
derived. Furthennore, the options manager contains a mechanism for identifying start-up options that must 
be set on initial start-up or each time the device is activated: Hie options managemrat architecture is 
illustrated in Figure 4. 
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Options 
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Figure 4 - Options Management Object Relationship 



Key elements of the options architecture are as follows: 

1 . Options Management Application: This is tiie application responsible for presenting the common 
access points to options. 

2. Options Management Service: This Alchemy™ service provides a root menu and a start-up list for the 
system. 

3. Root Menu: This is the root of the options tree. Options and submenus can be added, as required. 

4. Startup List, This is tiie list of options that need to be initialized at device start-up. Ihese options must 
be set on initial start-up or each time.the device is activated. 

5. Options Screens: These are the actual GUI implementations of options editing sheens for the available 
options. 

6. Invocation Indications: Alchemy™ decouples the invocation of an options screen from tiie user's 
dismissal of the screen. When the option screen is dismissed, the invocation indication is used to 
infonn the controlling application that user manipulation of the options screen is complete. 



4. 3 Language Management 

Alchemy™ provides a language management s^ce that maintains a list of available languages and a 
listener interface that supports notification of language changes. In addition, Alchemy™ provides a base 
language inter^Eice and a core language implementation from whidi application specific language object 
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can be derived. The language architecture is illustrated in Figure 5 for an application that extends the 
Alchemy^ core language interface. 



Language 




Figure 5 — Class Structure Language Management 



4.4 AWT Services 

In an AWT-style application environment, the developer has access to all AWT services supplied with 
PJava. While AWT services form the basis of the GUI application, Alchemy™ provides a number of 
services, mterfaces, and objects that tightly couple the AWT-based application to the multi-application 
architecture. 

4.4.1 Applications, Icons, and Selection 

AWT applications extend the base application interface with two objects, a generic panel, and an 
Alchemy^ specific AWT icon. The panel is used to house the GUI for the application itself. Whanevo' the 
application is activated, the panel is displayed. The icon is used to effect application selection. It contams 
an unage associated with the application and a reference to the application. The icon generates "^plication 
selected** events when a mouse click occurs on it The sequence involved in selection of an application is 
described below and illustrated in Figure 6. 

1 . A mouse click in the plication icon generates an "application selected event" which is received by 
the application selector. 

2. The application selector makes a request to the application manager to activate &e application. A 
reference to the application is supplied from the application icon. 

3. The application manager informs the application to activate and requests a reference to the application 
display panel. 

4. The application manager displays the panel and control is turned over to the application. 
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Figure 6 - Application Selection 



To speed development, Alchemy^** provides an AWT application RAD object that implements a shell 
application. This RAD object can be extended to achieve specific application functionality. 

4.4.2 Application Sefectors 

Alchemy™ provides an abstract base class for AWT application selectors. Several RAD AWT application 
selectors are also mciuded with Alchemy^, 



4.4.2.1 Sidebar Selector 

The AWT Sidebar Application selector implements an icon strip along one boarder of the screen that 
contains a set of icons associated with the device. When an icon is selected, its associated application is 
selected and displayed on the remainder of the screen* Scroll bars become active when the number of 
application icons exceeds the available real estate available to the sidebar. The sidebar application selector 
is illustrated in Figure 7. 




Figure 7 - Sidebar Application Selector 
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4.4.2.2 Comer Selector 

The AWT Comer Application selector implonents a small icon m tiie. comer of the screen that expands into 
a grid of application icons. When an icon is selected, its associated application is selected and the selector 
mi n imizes in the comer. The comer application selector is illustrated in Figure 8. 



Kit; J^^f 




Figure 8 - Corner Application Selector 



4.4.3 Options Manager 

Alchemy''^ provides a RAD object that implements a pull-down-menu-based options management 
application. It dynamically maintains the nested options associated with a device, and provides access to 
those options through a nested pull-down menu, llie options manager supports options screens that are 
implemented as panels. 



4.4.4 Virtual Keyboard 

Because many devices will be touchscreen-based. Alchemy""* provides full virtual keyboard support 
including an image-based, configurable virtual keyboard, and a virtual keyboard manager that provides 
tight integration between the virtual keyboard and text fields within an application GUI. 

The virtual keyboard is based on a multi-image ardditecture wh^e a visible image contains the user's view 
of the keyboard* and an underlying invisible image provides a Snapping to key values. Mouse clicks on the 
visible image are mapped by location (X, Y) onto ^e mvisible unage and the corresponding value in tiie 
invisible unage is conv^ted into a key value. The virtual keyboard generates ail standard AWT key events. 
The virtual keyboard also supports automated image replacement based on key presses. For example* when 
the shift key is pressed, the keyboard image can be changed to indicate capital letters. 

When active in a system, the virtual keyboard is automatically displayed when a text field gains focus. The 
text field is reproduced on the keyboard and input is accepted fix)m the user. After completion of the entry, 
the keyboard disappears and the text field is updated to contain the appropriate text. While this mechanism 
is automatic and requires no special consideration from the GUI deveiopo- to function, it can be 
cumbersome within a GUI implementation. First of all, the virtual keyboard covers the text that is being 
edited, so auxiliaiy infbrmation associated with the field (e.g., a field description) is likely to be hidden. 
Secondly, there is no general-purpose mechanism available to identify a particular keyboard style to 
associate with a particular text field. Lastiy, movmg from field-to-field involves dismissmg the keyboard 
when one field is completed and re-displaying it when another field is giv^ focus. Alchemy™ overcomes 
diese problems by providing a virtual keyboard manager. 

The virtual keyboard manager tightiy couples a set of text fields in a GUI implementation to the virtual 
keyboard by providing the follovydng capabilities. 

1. A field descriptor can be associated wift a text field that is registered with the manager. This 
description will be displayed on tiie keyboard while die text is being edited. 
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2. A specific style of keyboard can be associated wi& a text field that is registered with the manager. 

3. "Tab-OHiering*' can be established for a group of text-fields^ where the keyboard can be used to 
navigate &om field-to-fieid without being dismissed and redisplayed. 

An application environment that leverages the virtual keyboard manager can be made more user-iiiendly 
than one that does not 

Alchemy^ comes widi a number of RAD virtual keyboards including standard qwerty, alphanumeric, and 
keypad styles. 

4A5 Activity Source 

In support of idle detection mechanism, Alchemy™ provides a polled activity source for AWT 
environments. This source monitors AWT mouse and key events, and provides an indication of activity to^ 
the idle manager when polled This source elimmates the need for individual applications to contmually 
indicate activity to the idle manager (based on the premise that if the user is mteracting with the device 
through the mouse or keyboard^ then some application on the device must be active). 

4 

5 Smart Card Services 

An implementation of the Open Card Framework (OCF) is the cornerstone of Alchemy's smart card 
services. OCF is implmented within Alchemy^ as a service bean and includes terminal and terminal 
factory implementations for tiie AKP smart card reader, as well as a nimiber of 3"* party readers including 
the Gemplus GCR4I0 and Litronic 210. Using OCF, it is possible to support any smart card application by 
implementing an OCF service for the card application, and a terminal application that uses the service. 
Alchemy^ mcludes a number of RADOs lhat act as example service and tenninal application 
implementations. 

Because Alchemy™ is a dynamic multi-application envirorunent, it is designed to support multi-application 
card environments. To begin with. Alchemy™ provides a card detection service capable of asynchronously 
detecting card insertions and removals, and notifying registered listeners. When a card is inserted, existing 
OCF services are leveraged to determine the available card applications and a list of those applications is 
returned to the listener. Based on this list, an application selector or some other service witbin the device 
can select and activate a particular terminal/card application pah*. 

Alchemy*^ also supports dynamic download of smart card applications including both tenninal and card 
resident portions of a smart card application. Download support is delivered trough the gateway as 
described in section 8.4. Specific OCF services are available in Alchemy^ which support the actual 
download of applications to the card. 

NOTE: The first release of Alchemy'™ includes support for the Java Card environment only. Support for 
MultOS and other multi-application environments is deferred to a subsequent release of Alch^ny^. 

Finally, the OCF service is augmented with observation and control mechanisms that support remote 
monitoring of ISO 78 1 6 messaging at the card terminal. This capability facilitates debugging and testing of 
smart card applications. The observation and control architecture is described m section 8.1. 

5.1 Java Card 

Alchemy™ provides direct support for the Java Card 2.0 and 2.1 environments mcluding a full 
implementation of tiie Java Card simulation environment Simulation support is realized through the Java 
Card simulation manager, which allows the developer to create any number of simulated terminals and any 
number of simulated Java Cards. Each simulated card can be configured to contain a number of real Java 
Card Applets. The manager controls the insertion and removal of a simulated card into a simulated 
terminal. Once card insertion occurs, the interaction between card applets and card terminal applications 
can occur just as in a real Java Card environment Using the simulated enviroimient, it is possible to 
develop a card applet and terminal application in the workstation envirorunent and then migrate it to an 
actual terminal/card environment Alchemy's Java Card environment is illustrated in Figure 9. 
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The Java Card simulation manager is augmented with observation and control mechanisms that support 
remote control of card insertion and removal. See section 82 for details. 
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Figure 9 - Java Card Environment 



Alchemy' s implementation of CX^F contains q)ecific services that support do^load and deletion of applets 
on a Java Card. This support is leveraged by the gateway to achieve rmote management of the q)pHcation 
suite on a Java Card. See section 8.4 for details. 

6 Telephony Services 

Alchemy^ provides a number' of telephony s^vices including modnn support, basic telephony support, 
and advanced telephony support These services are described in the following subsections. 

6.1 Modem Services 

Modem services are based on Javax.comm, which defmes a standard mechanism for serial communications 
in Java. The modem service extends the Javax.comm serial I/O API with a modem control API that 
provides the fonctionality to initialize and configure the modem. Hie existing implementation is targeted at 
the V.90 modem available on Touchstone^, but the modem service is easily portable4o other modem 
solutions. 



6.2 Basic Telephony Services 

The basic telq)hony services available in Alchemy'^" are closely coupled to the Touchstone™ Telephony 
board capabilities. The basic telephony service bean provides a control API for direct control over telephony 
features, a status API for retrievmg telephony status, and an event list^er API for reception of asynchronous 
telephony events. All basic telephony services are summarized in the following table. 
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Tabie 1: Basic Telephony Services 



Feature/Description 


Control 


Status 


Event 


Initialization/Register Control 


X 






Vohixne 








Handset 


X 


X 




Speaker 


X 


■ X 




CAS Detection 




- 


X 


FSKDataRjBception 






X 


TypelCaU^ID 






X 


TypeaCallerlD 






X 


Visual Message Waiting 






X 


DTMF Tone Generation 


X 






Ring Detection 






X 


Extension In Use Detection 




X 


X 


Distinct Audible Ring Tones 


X 






Voice Path Control 








Handset 


X 


X 




Handsffee 


X 


X 




Microphone 


X 


X 




Hold/Mute/Uhmute 


X 


X 




Dial Pad Scan 






X 


Cradle Hook switch Scan 




X 


X 


Hook Switch Control 








On/Off hook 


X 


X 


X 


Flash 


X 




X 



6.3 Advanced Telephony Services 

While the basic telephony services described in the previous subsection provide access to all die telephony 
capabilities of the ARP, and as sudi, give the developer fme-grained control over these capabilities, the 
onus is on the developer to Integrate these capabilities into a functional telephony service. Alchemy™ 
includes a number of advanced telephony services that provide this higher level of integration, thus 
reducing the development effort required to deploy a telephony application. Advanced telephony service 
include the following: 

1. Voice Call State Machine: Provides intelligent control of incoming and outgoing voice paths with 
control over handset/handsfree modes, hold, and mute. Also bcludes persistent volume control for 
both handset and handsfiee, and persistent audible ring tone selection. 

2. Hook Switch State Machine: Provides integrated control and feedback of the hook switch and hook 
switch cradle. 
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3. Telephony/Modem Line Sharing State Machine: Provides intelligent sharing of the line between 
telephony and modem fiiDctioDality in a single-line environment 

4. Distinctive Ring Interpretation: Provided the ability to define distinctive ring interpreters that can be 
used in conjunction with CLID and other services to uniquely identiiy incoming calls. 

5. Audio Streaming and Playback. Provides voice path control and decompression streams for &e audio 
protocob supported ot the ARP. 

6. Contact Database: Provides a configurable contact database that ti^tly integrates with CLDD features. 
Provides underlying capabilities for caller log, preferred name matching, area code striping, etc. 

Alchmy mcludes a set of RAD objects that implement a full-featured telephony application based on the 
advanced telephony features desoibed above. Hiis application serves as both an example, and a starting * 
point for a device specific telephony application. 

7 internet Services 

Alchemy™ provides seamless access to the Internet, and as such, is designed to develop "Internet Aware" 
devices. Specifically, Alchemy"™ provides connection services, integration of 3"* party Internet applications 
such as browsers, and email clients, and custom URL handling for services and applications that reqiiire . 
integration with browser services. 

7.1 PPP and Auto Olal 

Dialup connectivity to the Internet via an ISP is supported through Alchemy*s Point-to-Point Protocol 
(PPP) and Auto Dial service. The PPP and Auto Dial service maintains a persistent list of ISP 
configurations. Each configuration contains the information required to make an ISP connection, including 
phone number, user ED, password, DNS Addresses, mail server, etc. Hie PPP and Auto Dial service 
provides an API that supports addition, deletion and selection of ISP configurations. Once selected, a 
particular configuration is used to automatically establish a connection when some other service or 
application activates TCP/IP services. The PPP and Auto Dial service is also remotely controllable through 
observation and control services. 

* 

7.2 Internet Applications 

Alchemy™ does not reinvent the wheel when it comes to Internet applications such as browsers and email 
clients. A number of Java-based "wnbeddable" Intemet application suites are commercially available from 
3"* party vendors, and these application suites can typically be integrated into Alchemy™ with little effort 
Aldiwny™ has been demonstrated to work with two Intemet applications suites, namely Sun 
Microsystems' Personal Applications'^ suite, and Espial Group's Escape'** browser andfibox™ eniail 
clieAt While Alchemy™ provides mtegradon for these application suites, the suites must currently be 
obtained directly firom their respective vendors. 

7.3 Custom URL Handling 

The existence of a browser on a device is useful for more than just traditional Intemet browsing applications. 
The HTML rendering capabilities of the browser can be leveraged into other on-device ^plications to deliver 
UI services. In such an enviroiunent^ the developer can use custom URL definitions to trigger events in other 
services or applications. Alchemy™ provides a custom URL dispatching service capable of mamtaiifking a list 
of custom URL types, ancl a set of listeners for each type. When the browser encounters an unknown URL 
type, it hands it to the dispatcher which, in turn, dispatches thfe URL to all interested listeners. 

This process is illustrated in Figure 10. 

As an example, consider the foUowmg: 

Alchemy:saveToDirectory?name-AudeSi Technologies Inc.&number=403-730-7555 
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This URL is not recognized by the browser so it is passed to the Custom URL dispatcher. It is then passed 
to the URL listeners. One of the listeners is the directory application that takes the URL and &dds-a new 
entry for AudeSi Technologies Inc. 



Unknown Event 




Figure 10 - Custom URL Dispatching 



8 Observation and Control Services 

The distributed nature of the Alchemy™ core provides direct support for remote instantiation of objects into 
a device load. Leveraging this mechanism, Alchemy™ delivers a complete observation and control (O&C) 
architecture capable of supporting system debugging, remote diagnostics, automated regression testing, and 
device management 

8. 1 Observation and Control Architecture 

The O&C architecture delivers two key capabilities to the developer. 

1 . Observation: The ability to extract infonnation firom the system is accompiiahed by implementing a 
specific observable inter&ce withm an object, and r^otely controlling the obs^ation process 
through an observer bean. Actual observations are passed torn the device through a remote event 
medianism. Obsmrations can be generic (e.g., text-based loggmg) or specific (e.g., ISO 7816 
messaging). 

2. Control: The ability to remotely control objects in tiie system is accomplished by implementing a 
specific controllable interface within an object and remotely controlling that object through a controller 
bean. Control Amotions are typically object specific in nature. 

Alchemy *s™ O&C ardiitecture and its major components are described below and illustrated in Figure 11. 

1 . O&C Registry: On the device side, the O&C registry is responsible for maintaining a list of all 
observable/controllable objects in the system. The registry communicates with a remote O&C manager 
to orchestrate a specific O&C session. All observable/controllable objects in the system must register 
with the registry to be actively observable/controllable. 

2. Obsenfahle/Controllable Object Any object in the system is observable/controllable if it unplements a 
specific observable/controllable interface, and it registers itself widi the O&C registry. The object is 
manipulated through a mated observer/controller object that knows the specific O&C inteiiace 
implemented by &e object. 

3. Observer/Controller Managed Bean: On the device side, the Observer/Controller is mstantiated as a 
temporary managed bean, and is responsible for manipulating observable/controllable objects of a 
specific type. Tlie observer/controller is remotely controlled by tfie O&C manager through a matching 
client bean on Uie server side. 
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4. Observer/Controller Client Bean: On the server side, the O&C manager transparently communicates 
with the device side observer/controller through the observer/controller client bean. 

5. O&C Manager, The O&C Manager controls the observation process through three primary functions. 

I. The manager maintains a registry of observer/controllers' that can be activated in the framework. 
When instructed to do so by some controlling test tool, ttie manager instantiates and activates an 
observer/controller in tiiie framework. 

II. The manage presents a configuration and control interface for test tools. It identifies all available 
observer/controllers, and allows the test tool to configure, activate and deactivate those objects. 

UI.The manager processes observation events and submits them to observation database. 

6. Observation Database: The Observ^on Database stores all &e observations for a session. Each 
observation is stored with a time-stamp, an observation class name, and the actual observation object 

7. Test Tool'. Any controlling ^plication can act as a test tool. A test tool may present a GUI to the user 
that allows hhn to configure, activate and deactivate observer/controllers in the system, or it may be a 
self-contained automatic test-harness. Test tools interact with the O&C manager to control an O&C 
session, and with the observation database to inspect observations. 
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Figure 11 - Observation and Control Architecture 



Because the O&C architecture is open and extensible, it can be leveraged to deliver any specific O&C 
capabiHties applicable to a particular device or service. Alchemy™ provides specific O&C capabilities 
through a number of tools, and observable/controllable objects as described in the following subsections. 

8.2 Alchemy ^ Observer/Controllers 

Alchemy™ provides a number of specific observer/controller objects that can be used directly by the 
developer including the following: 

1 . Text-based Logger, This observer performs generic text-based logging of events, and can be used for 
genial-purpose tracing. 
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2. Application Selection Observer, This observer generates observations that indicate application 
selection and de-selection activities.; 

3. ISO 7816 Observer: This observe generates observations for all smart card messaging that occurs 
between an OCF termma] and a smart card. 

4. Java Card Simulation Observer/Controller. This observer/controller interacts with the Java Card 
Simulation Manager to identify available simulated Java Cards and fecilitates simulated insertion and 
removal of those cards into a simulated terminal 

5. Basic Telephony Observer, This observer handles all basic telephony observations generated by the 
Alchemy™ basic telephony service. 

6. Persistent Storage Observer: This observer generates observations that contain persistent storage block 
maps. 

7. Modem Observer, This observer generates observations that include all control conmiands sent to the 
raod^. 

8. PPP and Auto Dial Observer: This observer-generates observations that identify all activities 
associated with PPP connections. 

8.3 Alchemy Probe 

Alchemy™ inchides a developers' probing tool. This tool provides a controlling GUI that is used to 
establish and control an O&C session. The probing tool was developed to support testing of Alchemy™, 
and as such, works with all Alchemy™ supplied obswrver/controllers. Theprobmg tool is based on an 
extensible architecture and can be easily modified to support any custom observer/controllar. The main 
features are described as follows: 

1. Coriflguration: Developers can configure an O&C session by establishing a connection to the device 
under test, and identifying the specific observer/controllers that are active. 

2. Watchpoints: Developers can set watchpoints for particular observations of mterest. 

3. Filtering: Developers can define filters on the properties of tfie observations. 

4. Database Interaction: The probing tool provides complete integration with the observation database 
for the storage and retrieval of observations. You can also archive and playback previous sessions. 

5. Formatters: Observations are not necessarily in human-readable form. The probing tooi provides the 
infrastructure to support custom hitcrpreters that can interpret and di^lay specific observations. 

6. Controller Interfaces: The infrastructure supports custom user interfaces that can be used to activate 
the control interface of observer/controllers. 

8 A Device Management Gateway 

The Device Management Gateway provides remote management facilities for devices under development, 
as well as deployed devices. The gateway is based on the Alchemy™ O&C architecture and delivers the 
following key c^abilities: 

1 . Discovery: This process involves determining tiie precise configuration of a device. Specifically the 
foUoiving information can be retrieved fix)m a device: 

1. System Properties: System properties can be retrieved either individually or as a group. 

n. Managed Beans: The managed bean repository can be queried for the existence of an individual 
bean or for a list of all existing beans. Managed bean queries return bean name, class, version, and 
depend^cy information. 

III. JARs: The JAR repository can be queried for a list of JARs and their CLASSPATH ordering. The 
amount of free space in the repository can also be determined. 
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IV. Java Cards': Card terminals can be queried for the exist^ce of Java Cards, and subsequently, each 
Java Card can be queried for a list of Java Card applets. 

2. Bean Management: This process involves manipulating the set of managed beans that exist in the 
device. Managed beans caii be added, replaced, and removed In effect, this service allows the 
application and service suite on the device to be customized remotely. Download services include 
automatic instantiation of new applications, automatic device restart (where required), and robust 
recovery from failed downloads. 

3. JAR Management, While bean management services automatically support downloading of new JARs 
associated with new applications and services, the gateway supports direct manipulation of JARs that 

• exist in the JAR repositoiy. Specifically, the gateway supports reordering of JARs in the JVM 
CLASSPATH, explicit deletion of JARs, and defiragmentation of the JAR repository itself. * 

4. Java Card Management: A Java Card that is inserted into an available card terminal can be managed 
.through the gateway. Specifically, ^plications can be downloaded to the card or deleted fi-om the card. 

• The gateway is implemented as an observer/controller managed/client bean pair, and as such, provides 
gateway capabilities to any server side controlling q}plication. Within Alchemy'"*, gateway facilities are 
deployed into the probing tool through a custom controlAmterpreter interfece. This interface acts as an 
example dqjloyment of the gateway that can be modified for a particular service environment, but also 
delivers fidl-featured gateway capabilities to the developer. 

9 Development Environment 

The underlying goal of Alchemy™ is to reduce the development cycle for mteihgent devices by providing a 
software infrastructure and service suite that can be rapidly deployed onto a hardware reference platform. 
While application development can be accomplished in any environment that supports Java, ultimately the 
Java code must be deployed into the target device on top of a properly configured RTOS/driver load. The 
Alchemy^ development environmoit supports this process through a set ofutilities and tools that augment 
and enhance your preferred development environment, without hnposing a specific environment or tool 
chain on the developer, furthermore, all Alchemy^ tools and utilities are written in Java and are delivered 
with full source code so that they can be tailored specifically to a preferred environment This means 
familiar development tools such as Java Integrated Development Environment ODE\ RTOS IDE, and code 
compactors sudi as the Embedded Java toolchain can be woven togetiier into a seamless development 
environment tailored specifically to your needs. While tiie development environment is adaptable to any 
hardware target, Alchemy^ provides specific mtegration for Touchstone''^, and will work with it out of tiie 
box. 

Alchemy™ includes support for the following aspects of the development cycle: 

1 . InstaUation: Installation wizards and scripts are included that perform a complete installation of the 
Aldiemy™ system mto your development environment 

2. Development Alchemy™ includes a complete makefile structure that will build all Alchemy^*^ 
software components. This structure can be easily extended to include new apptications and services. 

3. Packaging. Alchemy™ provides packaging tools that perform the following functions: 

L System Configuration Definition: Allows the developer to specify a particular hardware 
configuration that will be supported for a particular device. 

n. RTOS/Driver Cotrfiguration: Based on system configuration information, a RTOS/driver 
configuration can be automatically generated. 

ni. Application Suite Definition: Allows the developer to define an application load for deployment 
onto a device. AU application/service bean dependencies are automatically resolved to ensure a 
complete load. 

* 

IV. Code Compaction and Obfitscation: Based on a defined application load, code compaction and 
obfuscation can be performed to minimize the memory footprint of tiie load. 

V. JAR Creation: Single or multiple JAR files can be produced for download to the device. 
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4. Target Deployment Alchemy"™ includes boot-loader facilities for Touchstone""^ that are capable of 
downloading a target software load to the device. Support is available for stand-alone loads as weU as 
network-based loads. 

5. Test/Debug: As described earlier, Alchemy^ supports a r^ote observation and control environment 
for target testing and debugging. A number of test and device management tools are deployed under 
this architecture, including the probing too] and the gateway. 



SUBSTITUTE SHEET (RULE 26) 



wo 00/077750 PCT/CAOO/00703 



-37- 



1 0 Appendix A - Touchstone™ 

Touchstone™ a two-board solution composed of a logic board tiiat contains central processing and tbe 
bulk of the I/O capabilities^ and a telephony board that includes the telephony and modem capabilities. The 
functional specification for each of these boards is given below. 

Logic Board Functionality 

L MPC823(E) Processor Socketed 

2. Core Memory 

• CSC boot Flash - 4 Mbytes of onboard Flash, Full 32 bit interface 

• Nand Flash - 4 to 8 Mbytes of onboard, 16 bit interface 

• Compact Flash memory expansion (2-48 Mbytes modules) 

• ATA interface vs. Imear Flash will be dependant on existing Java 0S4C (i.e.. Chorus) support 

• 32Mbytes (max.) dedicated onboard SDRAM operating at the maximum processor bus speed. 

3. MPC82xLCD Controller 

• Common onboard LCD interface to provide complete access to all on chip LCD pins or dedicated 
LCD controller 

• Dedicated onboard LCD/CRT Controller mth 256KxI6 dedicated video DRAM, H/W provision 
oniy, EPSON SEDI355/6F0A - for part details www.erd,epson.com 



Target LCD for Reference Board 



Manu&cturer 


Part Number 


Pfacels 


Display Area 
0^)x(V)mm 


Technology 


Sharp 


LQ64D341 


640 X 480 


130x97 


TFT Color 



4. Party Resistive Touch screen 

5. Keypad, status indicator Interface 

• Offboard 2mm header to accommodate up to 6 x 6 keyscan matrix 

• I^C connections to provide 8 incremental GPIOs for LEDs (PCF8574) 

6. 16550 UART 

• Memory mapped UART with H/W flow control and dedicated intemipt 

• Dedicated inter&ce to modem V.90 on telephony board 

7.. Communication Ports 

All Channels use the CPM capabilities and therefore will be constrained only by the performance 

of the CPM and its Time Division Multiplexing capabilities. 

SCC2 

• IEEE 8023 compliant (based on MC68160 (Ethernet)) 

• IrD A p.4K to 4Mb/s) - H/W only 

SMCl 

• 1-7816 compliant full size, smart card interface 
SMC2 

• Non-isolated RS232 port 
USB 

• Dedicated keyboard interface - non compliant with USB host standards 
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I2C 

• 8 additional onboard GPIOs (PCF8574) 

• Digital potentiometer - LCD brightness control 

• 16KbEBPR0M 

SPI 

• Touch screen AID interface 

8. Development and Debug Capabilities 

• MPC823 BDM port (non-isolated) 

• Dedicated Logic analyzer ports for primaiy MPC 823 address, data and control logic 

• Memory mapped-debug LED*s 4 character, 5x5 ASCH mterface 

Logic Block Diagram 



System memory 



Expansion 
memory 




Hota; bc£rciBi8& nut 



Teldphony 



Onboard 
memofy 



video 
Memory 




CRTOutput 




MtSiCortiBI 
Apawv 



SIMS 





















tt'm' • 







Touch Saeen 



Logic board 

proof of port 
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Telephooy Board Functionality 

Processor Independent Telephony Solution 
1-line or 2-line operation ~ user configurable 

1, Une One Features 

• Full featured handset/handsfree capability 

• Type I and n Caller ID features. 

• Full duplex handsfree 

• Shared Voice or modem (l-Iine scenario) 

• Isolated PSTN inters 

• Does not include DTAD or Voltage Message Waiting capability 

• Powered only operation Le., no POTS operation 

2. 2>5P-based Handsfree and TrueSpeech ^ Audio (Line 2 only) 

• Integrated Full Duplex Handsfree 

• DTMF/Tone generation and detection 

• Audio streaming de/compression as per DSP Group CT8021 (See table below) 

• Other than basic DSP driver support^ functional driver support for listed incremental functions are . 
- ■ not supported. 



Supported Speech Coder 


Typical Application 


G.723.1 63 & 5.3 kbps 


H324 for video conferencing over dial-up V.34 modems 
H323 multi-media conferencing over LANs and TCP/IP type 
**packet-data" networks (e.g., Internet) 


G.728 16 kbps 


H320 for video conferencing over ISDN 


TrueSpeech 4.8 & 4.8/4.1 kbps 


Proprietary low bit rate coder 


16-bit or 8-bit Ihiear 
128 or 64 kbps 


Microsoft WAVE files 


G.7 1 1 Mu-Law/A-Law 
64 kbps 


Standard speech compression used in digital telephony systems 
(e.g., Tl/Bl) 


Downloadable Speech Coders 




TVueSpeech 8.5 

8.5 kbps 


DSP Group speech coder built into Microsoft Windows 95. 
Also used in some DSVD modems and Intmet Telephones 


G.729A+B 
8 kbps 


Optional speech coder used in H323 


G.722 
64 Kbps 


7 KHz Wide bandwidth ADPCM midio coder used in H320 
aSDN) • 



3. Line Two Features 

• Dedicated V.90 Modem interfece (2-iine scenario) 

• Isolated PSTN interface 

• TVp*^ 1 - Caller ID 
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Telepbony Block Diagram 



Block Diagram V1.3 




AuddSi Confidontiai -Notfor sxtemai distribution 
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We claim: 

1 . A method of providing a multiple smart card simulator comprising: 

(i) storing a first set of charactCTistics of a first smart card; 

(ii) creating a first smart card simulator simulating operation of said 
first smart card; 

(iii) storing a second set of characteristics of a second smart card; 

(iv) simulating operation of said second smart card thereby creating a 
second smart card simulator; 

(v) receiving a first input fix)m a first smart card application; 

(vi) modifying said fijrst input based on said first set of characteristics; 

(vii) sending a first modified input to said first smart card simulator; 

(viii) modifying said first input based on such second set of 
characteristics to fomi a second modified input; and. sending the 
second modified input to said second smart card simulator; 
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(ix) receiving a first output from said first smart card simulator 
generated in response to said first modified input; 

(x) modifying said first output based on said first set of characteristics 
to form a first modified output; 

(xi) transmitting said first modified output ta* said smart card 
^Ucation; 

(xii) receiving a second output icom said second smart card simulator 
in response to said second modified input; 

(xiii) modifying said second output based on said second set of 
characteristics to form a second modified output; and 

(xiv) transmitting said second modified output to said smart card 
application. 

2. The method of claim 1 where said characteristics include one of the smart 
cards memory size, command sequence, error handling routine or quirks. 

3. The method of claim 1 fiirther comprising the steps: 
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(i) receiving a second input from a second smart card application; 

(ii) modifying said second input based on said first set of 
characteristics; 

(iii) sending a third modified input to said first smart card simulator; 

-(iv) receiving a third output from said first smart card simulator in 
response to said third modified input; 

(v) modifying first said third output based on said first set of 

characteristics; 

(vi) transmitting said third modified output to said second smart card 
application. 

4. A method of simulating a multiple smart card euvironment comprising: 

(i) • detecting a snnulated smart card insertion (step 400); 

(ii) determining characteristics of the inserted card (step 405); 

(iii) notifying registered listeners (step 410); 
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(iv) detemrining available applications (step 420); 

(v) downloading to a simulated card and to a simulated terminal at 
least one sixiart card application (step 430) and 

(vi) repeating (steps 400 - 430). 
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Step TOO 


storing first set of cfiaracteristics of first 
smart card. 







Step 105 


Simulating operation of first smart card- 
creating a first smart card simulator. 







Step 110 


Storing second set of characteristics of 
second smart card. 







Step 115 


Simulating operation of second smart card- 
creating a second smart card simulator. 







Step 130 


Receiving input from smart card 
application. 







Step 140 


Modifying Input from step 1 30 based on 
characteristics of first smart card. 







Step 150 


Sending modified input to first 
smart card simulator. 







Step 155 


Modifying Input from step 1 30 based on 
characteristics of second smart card. 





X 



Figure 1A 
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Step 1 60 


Sending modified input to second 
smart card simulator. 




; 


Step 170 1 


Receiving output from first smart card 
simulator. 




1 


Step 180 


Modifying output from first smart card 
simulator with first set of characteristics of 
first smart card. 




i 


Step 190 


Transmitting first modified output to smart 
card application. 






Step 200 


Receiving output from second smart card 
simulator. 




1 


Step 210 


Modifying output from second smart card 
simulator with second set of characteristics 
of second smart card. 






Step 220 


Transmitting second modified output to 
smart card application. 





Figure 1 B 
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Step 300 


Receiving second input from second 
smart card application. 







Step 310 


Modifying second input based on first set 
of characteristics. 







Step 320 


Sending third modified input to first smart 
card simulator. 







Step 330 


Receiving a third output from the first 
smart card simulator. 







Step 340 


Modifying third output based on first set 
of characteristics. 







Step 350 


Transmitting third modified output to 
second smart card application. 





Figure 2 
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Step 400 


Generating a simulated smart card 
Insertion. 





4r Step 405 


Determining characteristics of the 
inserted card. 




; 


Step 410 


Notifying registered listeners. 




1 


Step 420 


Determining available applications. 




i 


Step 430 


Downloading to a simulated card 
and to at least one simulated terminal 
smart card application. 




i 


Step 440 


Repeating steps 400 to 430 





Figure 3 
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